As many trade journals indicate, MPLS-based VPN service is a lucrative business for the Service Providers and is rapidly growing. To provision VPN for a customer with many sites connected to service provider PE devices, one needs a network topology where each PE device is connected to other via tunnel LSPs. This can be done via different techniques. One widely used technique is a mesh-topology. This topology creates several problems for the providers; some of these are enumerated below:                (i) Connecting each PE by a tunnel LSP can potentially lead to a large number of LSPs and managing them can be very difficult for service providers.        (ii) Detecting data-plane lively-ness of the tunnel LSPs connecting the PEs using the MPLS-OAM techniques can cause sever scalability issues. Since MPLS-OAM places additional processing burdens on the Ingress and Egress LSRs, the number of tunnel LSPs and PEs involved in traditional VPN solutions, makes this fault detection technique difficult to deploy.        (iii) Deploying the recovery techniques using backup/alternative LSPs, in this environment is relatively inefficient and difficult to manage.        (iv) Supporting multicast and broadcast traffic (specifically while offering VPLS services) can be difficult to deploy.        
As an alternative to mesh topology, Star topology can be used. This reduces the number of tunnels needed, but does not address the issues related to MPLS-OAM, resiliency and multicast/broadcast traffic.
Virtual Private Networks (VPNs) have been widely deployed over MPLS-based networks as a new revenue generating service. RFC3031: Multiprotocol Label Switching Architecture, IETF Standards Track RFC, January 2001; RFC3021: MPLS Label Stack Encoding, IETF Standards Track RFC, January 2001, both of which are incorporated by reference herein. In a typical VPN scenario, customer sites at different locations are connected via a service provider network. Even though the service provider network is serving many different customers, each customer's traffic is treated separately from each other and given a virtual privacy. VPN services offered over MPLS networks can be grouped into PWE3, L2VPN and L3VPN categories.
In PWE3 VPN services, MPLS network is used just as a transport medium to tunnel customer traffic from one site to another one in its native format. PWE3 services have been defined for various traffic formats such as ATM, Ethernet, PPP, TDM, etc. For more information on PWE3 architecture and various PWE3 services, see IETF PWE3 Working Group, RFC3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3), IETF Informational RFC, September 2004; RFC3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture, IETF Informational RFC, March 2005; Luca Martini, et al. “Encapsulation Methods for Transport of Ethernet Over MPLS Networks”, Internet Draft, draft-ietf-pwe3-ethernet-encap-09.txt, February 2005; Luca Martini, et al., “Encapsulation Methods for Transport of Frame Relay Over MPLS Networks”, draft-ietf-pwe3-frame-relay-04.txt, February 2005; Luca Martini, et al., “Encapsulation Methods for Transport of ATM Over MPLS Networks”, draft-ietf-pwe3-atm-encap-07.txt, October 2004; Mallis, et al., “PWE3 ATM Transparent Cell Transport Service”, draft-ietf-pwe3-cell-transport-02.txt, February 2005; Vainshtein, et al., “Structure-Agnostic TDM over Packet (SAToP)”, draft-ietf-pwe3-satop-01.txt, December 2003; Andrew G. Malis, et al. “SONET/SDH Circuit Emulation over Packet (CEP)”, Internet Draft, draft-ietf-pwe3-sonet-10.txt, February 2005, all of which are incorporated by reference herein.
In the case of L2VPNs, a provider-provisioned layer2 VPN service is provided. An interesting L2VPN service is what is called a Virtual Private LAN Service (VPLS). VPLS emulates LAN across an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. In VPLS, MPLS network acts as if it were part of the customer LAN. IETF L2VPN Working Group, K. Kompella, et al., “Virtual Private LAN Service” draft-ietf-12vpn-vpls-bgp-04, February 2005; Marc Laserre, Vach Kompella, “Virtual Private LAN Services over MPLS”, draft-ietf-12vpn-vpls-ldp-06.txt, February 2005, all of which are incorporated by reference herein.
L3VPNs are defined for supporting provider-provisioned layer3 (routed) VPNS. In L3VPNs, MPLS network helps and participates customer's IP routing functionality. IETF L3VPN Working Group, E. Rosen, Y. Rekhter, “BGP/MPLS IP VPNS”, Internet Draft, draft-ietf-13vpn-rfc2547bis-03.txt, October 2004, both of which are incorporated by reference herein.
FIG. 1 illustrates common VPN architecture reference model used at all MPLS VPN services. In general, customer edge (CE) devices are connected to provider edge (PE) devices. The provider devices that are not directly connected to CE devices are called core provider (P) devices.
In FIG. 1, CEa sends all traffic destined to CEb to PEx. Then, PEx will do the following:                First, there has to be a label switched path (LSP) connecting PEx to PEy. This is called a tunnel LSP.        PEx will push a label for traffic coming from CEa destined to CEb via PEy. This is called a VPN label and it helps PEy to determine this packet has to go out to CEb.        Then, PEx pushes the tunnel label for the LSP connecting PEx to PEy.        
These operations will ensure that packet arrives at PEy. Then, PEy will process this packet as follows:                First, pop off the top tunnel label.        Then examine the second level label. If it is the VPN label for CEb, sent packet out to CEb.        
Please notice that this two level label stacking approach ensures that P devices do not have to know CE devices and their VPN labels. Only think P devices process is the tunnel LSPs connecting PE devices. As a result, this results in a scalable P device architecture.
In general, for a customer with N sites (say CE1 through CEn) connected to M PE devices (say PE1 through PEm), we need a network topology where each PE device is connected with each other via tunnel LSPs.
There are various ways of connecting PE devices via tunnel LSPs. One simple approach is to use a mesh topology where a separate and dedicated LSP is setup between any pair of PEs. For M PEs, this will result in M^2 tunnel LSPs. Another approach is to use a star topology. In this case, each PE is connected to a central core router. It is this central core routers responsibility to switch PE-to-PE traffic. This will result in a total of M LSPs for M PE devices.